Mobility Unified Reporting System Overview

 

 

This chapter provides an overview of the Mobility Unified Reporting (MUR) application.

This chapter describes the following topics:

•	Introduction

•	MUR Architecture

•	Distributed Architecture of MUR

•	MUR Deployment

•

Licensing

•	MUR System Requirements

•

MUR Ports

 

Introduction

The Cisco Mobility Unified Reporting (MUR) system is a Web-based application providing a unified reporting interface for diverse data from Cisco Systems In-line service and storage applications.

 

The MUR application enables:

•	Generating customized reports and comparison charts.

This release of MUR only supports generating HTML-based historical canned reports displaying data in graphical—graphs/charts—and tabular formats. Reports for ad-hoc periods are not supported. For information on the various reports supported, see the Report Types section.

•	Analyzing the reporting data and enabling the operator to get a full understanding of the performance of the network, enabling operators to optimally configure and plan their network.

•	Supporting distributed installation which allows to view reports from multiple sites.

•	Rich visualization (Graphs/tabular form).

•	Exporting reports in Microsoft Excel, Adobe PDF, and CSV formats.

The MUR application is available for report generation only when you install the software application on to your local server. For information on the server recommendations, refer to MUR System Requirements section in this guide. For information on how to install the MUR application, refer to Managing MUR Installation chapter in this guide.

The MUR application provides comprehensive and consistent set of statistics and customized reports, report scheduling and distribution from ASR 5000 system i.e. the chassis / in-line service product. For example, a subscriber's Quality of Experience, top 10 users, and so on.

The MUR application provides reporting capability for Content Filtering (CF) data, bulk statistics, Key Performance Indicators (KPIs), EDRs data from in-line service and storage applications. The MUR application facilitates and enhances the operators’ ability to simply and easily determine the health and usage of the network.

Important: In RHEL-based deployment of MUR, L-ESS is NOT required as the ASR 5K Enhanced Charging Services (ECS) module can be configured to push the xDRs directly to the MUR reporting server. Push from ASR 5K is the Cisco recommended deployment model. Currently L-ESS is supported only on Solaris platforms. For information on the L-ESS installation instructions, refer to the Cisco ASR 5000 Series ESS Installation and Administration Guide. Existing deployments where L-ESS is installed, to pull EDRs from ASR 5K, may continue with their deployment model in the 12.0 version of MUR Software Release and later.

The Unified Reporting system receives EDR data from the chassis only when the ECS module is enabled and configured to generate reporting EDRs. To enable this, you must purchase and install ECSv2 license on the chassis. For information on obtaining and installing the license, see System Administration Guide and Enhanced Charging Services Administration Guide. For information on configuring the ECS module, see Configuring Chassis for MUR chapter in this guide.

MUR receives the following types of EDRs for report processing:

•

CF-EDRs

•

Flow EDRs

•

HTTP EDRs

To reduce disk space and improve performance, MUR limits the bucket distribution for EDR data to ONLY last 2 days in case a EDR is spanning across more than 2 days or so.

For example, if the following EDR is received:

#sn-start-time,sn-end-time,radius-calling-station-id,ip-subscriber-ip-address,sn-subscriber-port,ip-server-ip-address,sn-server-port,sn-app-protocol,p2p-protocol,traffic-type,voip-duration,sn-volume-amt-ip-bytes-uplink,sn-volume-amt-ip-bytes-downlink,sn-volume-amt-ip-pkts-uplink,sn-volume-amt-ip-pkts-downlink,bearer-3gpp rat-type,radius-called-station-id,bearer-3gpp imei,ip-protocol,bearer-3gpp sgsn-address,sn-flow-start-time,sn-flow-end-time 1275330600,1275334200,9689944191,19.19.1.1,35111,1.1.1.1,21,8,,,0,52428800,1048576,100,200,1,apn.org1,35302703-090362-52,6,1.1.1.3,1275330600,1275334200

MUR determines the difference between the starttime and endtime attributes and limits the bucket distribution as shown here.

#starttime,endtime,protocol,rxbytes,txbytes 2011/02/26 10:00:00,2011/02/28 10:00:00,HTTP,100MB,100MB

Important: The bucket distribution calculation will remain intact i.e. the volume will be distributed equally among all the half-hour’s buckets that fall in the starttime and endtime.

Important: The MUR receives the data in terms of EDRs which are generated based on the flow. As the EDRs are flow-based and the bulkstats is a real-time data, the volumes reported in the EDR are different from the volumes reported by bulkstats.

For more information on using the MUR application to generate reports, see the Cisco Mobility Unified Reporting System Online Help documentation.

 

Report Types

The MUR application supports generation of canned statistical reports that can be used to analyze network performance, and decide the policies for users, and identify the customer trends, network usage patterns, network categorization, etc. The reports can be per gateway, or multiple gateways (region), or for the overall network. The reports can be generated for the usage of different entities such as gateway, content type, etc on an hourly, daily, weekly, or monthly basis.

The typical canned reports that are supported for the MUR application include:

•	Historical summary reports (Daily/Weekly/Monthly)

•	Half-hourly Reports: Usage reporting for the specified time period

•	Daily Reports: Usage reporting for the past 24-hour period (midnight through midnight)

•	Weekly Reports: Usage reporting for the past seven day period (Monday through Sunday)

•	Monthly Reports: Usage reporting for the past 30-day period (1 day of the month through the last day of the month)

•	Top “N” Reports

•	Statistical and analytical reports

•	Bulkstats and KPI reports

The static report layout comprises the following sections:

•	The report name

•	The report ownership: the user account that requested the report

•	The date and time of generation

•	The list of report parameters

•	The chart legend (displayed under the chart)

On the interactive layout the user can set a series of preferences in a specific manner. The user has the flexibility to change the type of chart from Bar to Pie (supported output types depend on the selected report). Changing the preferences like the chart type or report parameters will cause the report to refresh in the same window.

The interactive chart layout provides the following list of features:

•	Tool tip: When the mouse pointer stops over a chart series, after a short time a tool tip is displayed showing the information of the targeted sample.

•

Dynamic legend: The legend is located beneath the chart and is used to recognize the series plotted on the screen. In case of series representing either network services or subscriber packages, the colors are bound to the service/package names. This means that, for example, the HTTP Service will be rendered with a specific color for the reports. The legend is usually displayed with check-boxes associated to each color.

The MUR application provides the following reports:

•	Traffic Analysis Report: The Traffic Analysis report provides the total usage traffic (including uplink and downlink traffic) details for the following application categories:

•	Filesharing

•

Web

•

IM

•

VOIP

•

Standard

•

Streaming

•

Tunnel

•

Gaming

•	Unclassified

The usage traffic is expressed in terms of megabytes (MB) or Megabits per second (Mbps) and percentage (%). The traffic can also be in gigabytes (GB) / kilobytes (KB) / bytes depending on the magnitude.

•	Traffic Distribution Report: The Traffic Distribution report provides the summary of total traffic distribution for all the protocols application categories over a specified time period. The usage traffic is represented in GB/MB/KB/Bytes and percentage.

•	Active Flow Count Report: The Active Flow Count report provides the details of traffic distribution flow count against the different application categories. This report also provides the summary of total number of flows in the EDR records.

•	Unique Subscriber Hits Report: The Unique Subscriber Hits report provides an overview of the usage patterns of the entire subscriber population per protocol, for example, how many people are actually using VoIP.

Typically, this report provides the total number of times a subscriber is using a specific protocol for a predefined time period. These reports are displayed for all configured gateways.

•	TopN versus Total Traffic Report: This report provides the summary of total usage traffic and Top N subscriber traffic for all the protocols over a specified time period. The usage traffic is represented in GB/MB/KB/Bytes and packets.

•	TopN Subscribers Report: The TopN Subscribers report simply counts the number of bytes per subscriber for different time intervals. It displays the top 10/100/1000 subscribers for each hour and for each day/week/month/year. This report is displayed for all configured gateways.

Important: This report can be generated for only a single date.

After identifying the total amount of transferred data per subscriber, and identifying the top users, to understand the protocol and services breakdown for each subscriber, this report allows listing the different applications used by the top 10/100/1000 subscribers.

•	TopN VCD Subscribers Report: The TopN Voice Call Duration (VCD) Subscribers report displays the top N subscribers based on their voice usage (voice duration) for Yahoo, MSN and Skype voice protocols. The summary report displays the voice summary (voice duration) for VoIP category.

Important: This report can be generated for only a single date.

•	Weekly Report: The weekly report provides details of the following:

•	Total traffic

•	Total traffic by category

•	VOIP Call Duration

•	Total unclassified traffic (TCP and UDP)

•	Top N subscribers

•	Monthly Report: The monthly report provides the details of total traffic across the top N protocols / application categories in a month.

•	Offline Reporting: MUR supports on-demand offline reporting of subscriber specific information to operators. This ad-hoc request could be a subscriber search request or top N% subscriber search request.

Offline Subscriber Report: The MUR aids in searching individual subscribers based on IMSI/MSISDN, and generates a subscriber-specific report showing the list of URLs visited by the subscriber, and other details like QoS, usage traffic, aggregate application/protocol breakdown, etc for the specified time period. MUR mainly supports this search functionality to track a subscriber or a set of subscribers for lawful intercept.

To use this Offline Reporting feature seamlessly, you must configure the EDR Filename Format appropriately through the Gateway configuration from ADMIN tab, and organize the archive directory date-wise. For information on how to manage the archive directory, see the Managing Archive Directory section in the MUR Administration and Management chapter of this guide.

The offline subscriber report provides information on the following subscriber’s attributes:

•	Flow-EDR attributes

•	Application name (Category/Protocol/Application Detection and Control)

•	Traffic counters

•	Voice Duration counter

•	HTTP-EDR attributes

•

Http-Host

•	Http-Content type (MIME Types)

•

Http-URL

•	Transactional Traffic Counters

Offline Top N% Subscribers Report: MUR also facilitates to generate an offline report that covers the % of volume used by top n% users. This report provides information on the absolute number of users and the list of MSISDNs to facilitate correlation with the provisioning data. This Top N% reporting is purely based on APN Group(s). Hence, it is mandatory to configure APN or a group of APNs as necessary.

For more information on these features, see the Cisco Mobility Unified Reporting System Online Help documentation.

•	DPI Report: The Deep Packet Inspection (DPI) reports are the canned statistical reports at the gateway level. You can configure the MUR application to generate the reports for any of the available gateways.

In this release, MUR supports generating daily, weekly and monthly summary details and busy hour traffic usage details for the following report categories:

•	Traffic Analysis Report

•	Traffic Distribution Report

•	Active Flow Count Report

•	Unique Subscribers Hits Report

MUR has the capability to report the following details per protocol:

•	Total volume for the day/week/month

•	Volume distribution in the busy hour

•	Peak performance for the day/week/month

•	Maximum number of unique subscribers

Busy Hour Reporting: Busy Hour (BH) reporting is mainly useful for the users to monitor different traffic flows in their network during the busy hour. BH indicates the sliding 60-minute period during which occurs the maximum total traffic load in a given 24-hour period.

Please note the following key points:

•	BH reporting is available ONLY on the GUI and not in xls format.

•	BH reporting is available only under the DPI tab.

•	BH radio button is available on the date panel.

•	BH reporting is available for a date, date range, week and month.

•	Busy hour reports are currently available ONLY at the NOC level.

•

CF-RE Report: Content Filtering (CF) solution enables operators to filter HTTP and WAP requests from mobile subscribers based on the URLs in the requests, so that subscribers are inadvertently not exposed to universally unacceptable content and/or content inappropriate as per the subscribers’ preferences.

The CF-RE report provides the summary of traffic over CF categories, CF actions, and CF ratings. The CF actions that can be taken on the URL are as follows:

•

allow

•

discard

•	redirect-url

•	content-insert

•	terminate-flow

•	reply-code-terminate-flow

The CF ratings can be one of the following:

•

dynamic

•

static

•	blacklisted

The CF-RE report also provides the list of top N subscribers and URLs based on their unique subscriber’s hit count and total usage.

•	HTTP Reports: The MUR application parses HTTP EDRs and then provides the following details for any specific day, week, month and date range:

•	Total traffic per HTTP group / host name and HTTP content type

•	URL hits per HTTP group / host name and HTTP content type

•	Unique subscriber count per HTTP group / host name

Typically, MUR supports the following categories of HTTP reports:

•	Summary reports — Content type/subtype volume report available for daily, weekly, monthly, and date range

•	Top N reports (Daily/Weekly/Monthly)

•	Content Type Aggregation — Top N Content type by Volume; Top N Content Type by Hits

•	HTTP Group Aggregation — TopN HTTP group by Volume; TopN HTTP group by Hit count; TopN HTTP group by Unique subscriber hits

•	Top N Referrer Group Aggregation by Hit count

•	TopN User Agent (UA) reports available for APN-TAC combination in addition to individual per APN, per TAC reports.

The top N referrers’ report provides details of the total hit count for top N referrers and their sub-domain wise traffic distribution.

Important: In the distributed model of MUR, the data received from RDP is populated and Top N referrer reports are generated only at Master MUR. The report is available for RDP as well as master MUR.

Important: It is mandatory to configure http-url and http-referer fields in the EDR records for top N HTTP referrers report generation.

•	Bulkstat Report: The Bulkstat report provides details of the processed bulk statistics from any application (PDSN, GGSN, SGSN, and so only) on the managed nodes in a timely manner.

Important: Make sure that you configure the bulkstats schemas through the GUI to generate bulkstats reports for any of the available gateways. For more information on schema configuration, refer to the Configuring Bulkstats Schemas Using GUI section in this guide and also Cisco Mobility Unified Reporting System Online Help documentation.

The bulkstat data is sent from the gateway to the MUR server with GMT (UTC Time stamps). The bulkstat file processing is triggered by the MUR scheduler engine. The scheduler processes the bulkstat files line by line for each gateway, and gets the schema, timestamp, and key index. If the index does not exist, the parser creates index and inserts data into bulkstats data table. Once the processing is complete, this data file is moved to the archive directory. Summarization must happen as the user moves from gateway to higher levels.

Important: For Bulkstat, there is no support for distributed model and all the bulkstat input files will be parsed by master MUR system only.

MUR supports generation of busy hour reports, top N Min/Max reports, performance aggregation reports i.e. daily, weekly and monthly summary reports.

Please keep the following key points in mind for bulkstats reporting:

•	The gateway(s) and MUR server need to be NTP synced for accurate BS aggregation reports.

•	Hourly aggregation reports are triggered at 50th minute of every hour.

•	Daily reports are scheduled at 3:45 PM the next day.

•	Weekly reports are scheduled at 5:00 PM every Monday.

•	Monthly reports are scheduled at 06:15 PM on 1st of every month.

•	KPI Report: The KPI report provides details of the KPIs for each selected schema. KPIs are the formula-based calculations of selected bulk statistics counters. You can configure the MUR application to generate the reports for any of the available gateways.

For more information on each of these reports, see the Cisco Mobility Unified Reporting System Online Help documentation.

Important: Please note that the Bulkstats and KPI reports are displayed based on the gateway’s time zone.

Important: Please note that the subscriber’s private data like Mobile Station Integrated Services Digital Network (MSISDN) will appear encrypted in all the subscribers reporting. Users with administrative privilege can only decrypt the MSISDNs using a shell script utility. For information on how to use this script, refer to the MUR Administration and Management chapter in this guide.

Important: Please note that the availability of any report is typically based on the date/date range configurations and purging interval. If you are trying to view a report beyond the configured purging interval, MUR system will display an error message indicating that the report is unavailable.

 

Exporting Reports to Other File Formats

The MUR application supports exporting reports to the following file formats:

•	Microsoft Excel format: To export a report to Microsoft Excel format, use the get_excel_report script in the CLI. For more information about this script, refer to the Generating Reports in Excel Format section in the MUR Administration and Management chapter of this guide.

Exporting of reports to Excel format is also possible through the GUI by clicking the excel icon present in the tabular view of each of the reports under HOME and DPI tabs.

•	Comma Separated Value (CSV) file format: To view reports in CSV format, in the HOME and DPI tabs, click the csv icon present in the tabular view of each of the reports.

•	PDF format: To export a report to PDF format, in the HOME and DPI tabs of the MUR GUI, click the PDF button. The PDF file is displayed in a new window and can be saved for future reference.

If there is no data available for a report, the PDF button is disabled.

•	Text File format: This format is applicable only to HTTP User Agent (UA) reports. To export this report in a text file, click Export to Text button available in the HTTP UA reporting page.

For more information, see the Cisco Mobility Unified Reporting System Online Help documentation.

 

MUR Architecture

The MUR solution consists of two components — a server and a GUI client. The following figure shows a typical organization of the MUR solution.

 

Internal Architecture of MUR

The server components include:

•	DB Server: This is the standard PostGreSQL 8.3 database server. This is started at the time of application startup.

MUR uses pgbouncer utility for postgres connection pooling. This utility gets started/stopped with Postgres Server.

•	Quartz Scheduling Engine: This is the core of the MUR reporting solution. It is used to schedule different tasks such as parsing of incoming data files (bulkstat, EDR, etc.), trigger various canned reports on a periodic basis, cleaning up of stored outdated data and files, and so on.

•	Generators: These are python based scripts that are used for parsing various CSV files. The files are parsed to an extent where generated files (or data in database) themselves represent meaningful data. This is a very powerful concept introduced for faster processing of information.

The generators archive the files once they are parsed. In archival, the files are zipped and placed in the configured location.

•	KPI Parser: The KPI Alarm Generator uses the information stored by bulkstat parser in the database for KPI calculations and then, based on the calculations, generates the alarms that are subsequently sent to Network Node Manager (NNM).

•	Notif Server: This stands as a separate entity that collects information from the MUR system and generates alarms which are then sent to the NNM for further analysis.

•	Loggers: The MUR application uses various loggers so that application logs with various severities are made available for debugging purpose.

Some of the components at the client side include Django and Mod_python.

 

Distributed Architecture of MUR

MUR supports the distributed model to allow the deployment which enables network wide view or work load balancing. Newly introduced component, Remote Data Processor (RDP), plays the role of pre-processing the input files from gateways. One or more RDPs, installed separately on remote machines can be registered to a master MUR and one RDP can process files from one or more gateways.

RDP periodically sends the intermediate data to registered master MUR. The role of MUR in such deployments is mostly for report generation, report viewing, RDP management and optionally data processing.

Important: RDP installation and registration is required only for network wide deployments. For standalone installation no RDP is required. For information on how to install the RDP, refer to the Managing MUR Installation chapter of this guide.

Important: Make sure that you first install the master MUR system and then proceed with the RDP installation. Also, note that the RDP and MUR must be installed, upgraded, and uninstalled separately.

Important: Before registering RDP with the master MUR, ensure that the RDP is installed and running.

Important: The RDP management like configuration and removal is possible from MUR GUI only. For information on managing the RDPs, refer to the Cisco Mobility Unified Reporting System Online Help documentation.

Important: For Bulkstat, there is no support for distributed model and all the bulkstat input files will be parsed by master MUR only.

The following figure illustrates the distributed architecture of MUR.

 

Distributed Architecture of MUR

 

How RDP works with MUR

This section describes how the RDP works with the MUR application.

The RDP parses the raw data or EDR files from one or more GGSNs and populates the database for required reports. The RDP pre-processes the data and then periodically forwards them to the master MUR through SFTP for report generation.

Important: If the distributed model of MUR is used, then the SFTP user name and password should be the same as the MUR Administrator user’s login name and password provided during installation. For information on configuring SFTP details, see the Cisco Mobility Unified Reporting System Online Help documentation.

Each of the RDP and MUR will be assigned a unique ID during installation and will be used for identification of each RDP along with its gateway and data.

 

MUR with RDPs in Distributed Model

Each of the registered RDPs will form a new region. RDP region can be a child of the root of the MUR (NOC) or can be the child of another region. However, all the gateways associated with a RDP will always be the children of RDP region.

Important: Only single MUR can communicate with an RDP simultaneously.

 

MUR Deployment

The following figure illustrates how the MUR reporting server interacts with the gateways and generates the reports.

 

End-to-end Component Mapping

The chassis / gateway supports on board Hard Disk Drive (HDD) for extended storage of the xDR files such as EDR, UDR, CDR, and NBR. If the HDD is configured, then the gateway pushes the files to an external entity like External Storage Server (ESS) for short-term storage. In case of no HDD support on the gateway, the Local, short-term External Storage Server (L-ESS) has the capability of pulling the files from gateways via SFTP, and send it for report processing. For more information on L-ESS, refer to the ESS Installation and Administration Guide.

The MUR server collects the EDRs, and bulkstats from gateways or L-ESS server, and processes the incoming data files and presents reports on Web-based GUI. The MUR application can generate reports in Excel, CSV, and PDF formats, and present them to users on a request basis.

Important: L-ESS is NOT required as the ASR5K EDR module can be configured to push the xDRs directly to the MUR reporting server. Push from ASR 5K is the Cisco recommended deployment model. Currently, L-ESS is supported only on Solaris platforms. For information on the L-ESS installation instructions, refer to the Cisco ASR 5000 Series ESS Installation and Administration Guide. Existing deployments where L-ESS is installed, to pull EDRs from ASR 5K, may continue with their deployment model in the 12.0 version of MUR Software Release and later.

For information on how to configure the chassis to push the xDRs, refer to the Configuring Chassis for MUR chapter in this guide.

 

Licensing

For information on licensing requirements for the MUR application, please contact your local sales representative.

 

MUR System Requirements

This section identifies the minimum system requirements that are required for the deployment of MUR at the operator’s premises.

Important: The hardware required for MUR may vary depending on incoming EDR generation, subscriber count, and number of gateways.

 

Server Recommendations for Use in Solaris Environment

This section identifies the minimum system requirements recommended when installing the MUR application in Solaris environment.

NEBS Requirements:

The following are the server specifications for MUR when an additional external storage is required:

•	Sun Microsystems Netra™ X4270 server

•	Quad-Core two socket Intel Xeon L5518 processor

•

32GB RAM

•	2 * 300GB 10K RPM SAS disks

•	SATA DVD drive

•	8 internal port SAS HBA

•	Choice of AC or DC power supplies

•	Sun StorageTek 2540 SAS Array, Rack-Ready Controller Tray

•	12 * 300GB 15K RPM SAS drives

•	Two redundant AC power supplies

•	Operating system:

•	Sun Solaris 10 with latest patches installed

Non-NEBS Requirements:

The following are the server specifications with only the internal storage used:

•	Sun Fire X4270 server

•	Intel Xeon processor 5500 series

•

32GB RAM

•	16 * 300GB 10K RPM SAS disks

•	SATA DVD drive

•	Operating system:

•	Sun Solaris 10 with latest patches installed

Important: It is strongly recommended to update the Operating System with the latest security patches.

Important: The number of disks recommended is purely based on the throughput of the network and data retention configuration. Please contact Cisco Advanced Service Team for data sizing.

ZFS Pooling Recommendations

This section provides information on the recommendations for ZFS pooling.

•	OS pool: This mirrored ZFS pool shall be created for Solaris OS installation.

•	MUR pool: This standard ZFS pool shall be created for MUR i.e. MUR installation, incoming data files.

•	Postgres pool: This standard ZFS pool shall be created for MUR postgres database.

•	Archive pool: This standard ZFS pool shall be created for retaining archived and data backed up files.

Important: ZFS pool shall NOT be created with RAID-Z since ZFS does not allow attaching an additional disk to an existing RAID-Z pool. Hence, this freezes the chances of data scaling.

 

Server Recommendations for Use in RHEL Environment

This section identifies the requirements of server recommended when installing the MUR application in RHEL environment.

 

•	UCS C460 M2 server

•	4 x Intel® Xeon® E7-4860 @ 2.26 GHz, 130W 10 Core CPU / 24 MB Cache

•

64GB RAM

•	12 * 600 GB SAS 6G, 10K RPM

•	RAID Controller

•	4Gb Dual port FC Host Bus Adapter

Important: The number of disks recommended is purely based on the throughput of the network and data retention configuration. Please contact Cisco Advanced Service Team for data sizing.

•	Operating System

•	Cisco UCS running OS version ‘Cisco MITG RHEL 5.5’

For information related to OS installation, refer to the Cisco MITG RHEL OS v5.5 Application Note.

Important: The Cisco MITG RHEL v5.5 OS is a custom image that contains only those software packages required to support compatible Cisco MITG external software applications. Users must not install any other applications on servers running the Cisco MITG v5.5 OS. For detailed software compatibility information, refer to the Cisco MITG RHEL v5.5 OS Application Note.

Important: ZFS Pooling recommendations are applicable ONLY for Solaris hardware.

•	XFS/EXT-3 File System Volumes & RAID Recommendations

Important: For further details on the file system volume and RAID recommendations, please contact Cisco Advanced Service Team.

 

MUR Ports

This section provides information on various ports and their corresponding port numbers used by the MUR application.

Various ports are used by the MUR for both client-server communication and communication with ASR 5000 system. If firewalls are used on these interfaces, these ports need to be opened.

The following table lists the ports that are used by MUR.

Default Port Utilization

Port Name	Port Number	Usage
TCP Port	22	This port is used by MUR administrator to connect via SSH to UNIX command line on MUR servers for system administration. This port is also used by gateway to upload files via SFTP to MUR servers (stand-alone master and RDPs), and also by RDPs to upload files to the master. In the case of pull model, the L-ESS process on the RDPs or stand-alone master will use SFTP to connect to this port on the gateway. This port is also used between master MUR server and gateway to configure and upload bulkstat files.
TCP Port	25	This port is used to send e-mails to a mail server in case these are configured to deliver reports and alarms.
UDP Port	162	This port is used to send traps to the northbound network management system.
Postgres Port	5432	This port is used by the local processes to access the PostgreSQL server and can be restricted to prevent external access.
pgBouncer Port	Postgres Port + 1	pgBouncer is a utility used by MUR for postgres connection pooling. MUR installer picks up the port number next to postgres port for this utility. For example, if Postgres port 5432 is specified during installation then port number 5433 will be used by pgBouncer.
Apache Port	8080	For a standalone model: This port is used for communication between client workstation and Apache Webserver on MUR via HTTP. For distributed model: This port is used for both Master to RDP and RDP to Master RPC communication. Important: When firewall is used, Apache is the only port that should be kept opened.
RPC Port	9999	This port is used by the XML-RPC daemon of Scheduler component to listen the scheduling requests from the other MUR local components.

‌

Typically, MUR starts all its related services with non-root (i.e. muradmin) privileges.

 

Firewall Settings

When MUR is running on RHEL platform, Firewall is ON by default. In that case, user will NOT be able to get access to MUR GUI. The Firewall MUST be disabled with the following commands:

service iptables save

service iptables stop

chkconfig iptables off

 

Using Apache Port

This section provides information on how to configure the Apache port to use in conjunction with the MUR reporting server.

 

Using Apache in Solaris

In case the user wants to configure Apache port as 80 (i.e. < 1024), it is necessary to run the following command as root user so that muradmin can start the services on ports < 1024.

usermod -K defaultpriv=basic,net_privaddr <mur admin user>

 

Using Apache in RHEL

Important: Make sure that you disable Firewall before using the Apache port in the RHEL environment.

RHEL does not allow port 80 to be used by non-root users. However, Apache Web server requests made on Port 80 can be redirected to a port >1024 defined by the operator, with the following two commands:

iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j REDIRECT --to-port <user defined port> 1024>

iptables -t nat -AOUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-port <user defined port> 1024>

For example, to redirect requests made on port 80 to port 8080:

iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j REDIRECT --to-port 8080

iptables -t nat -AOUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-port 8080

Once this is done, user will be able to access the MUR GUI directly, without specifying the port in the Web browser URL http://<serveripaddress>

 

 

Cisco Systems Inc.

Tel: 408-526-4000

Fax: 408-527-0883